راه‌حل‌هاي تجاري 
●بسياري از سازمان‌هاي بزرگ تجاري داراي چندين سيستم اطلا‌عاتي مثل سيستم‌هاي ERP يا SCM هستند. 

اين سيستم‌ها ممكن است حتي تحت چند پلتفرم يا موتور پايگاه داده‌اي مختلف در سطح آن سازمان پراكنده شده باشند. بنابراين جمع‌آوري اطلا‌عات و مقايسه و نتيجه‌گيري از چند منبع اطلا‌عاتي مختلف بدين شكل، كار بسيار مشكلي است. 

حتي در صورتي كه بخواهيم در چنين سازمان‌هايي، فقط يك منبع اطلا‌عاتي را مورد تجزيه و تحليل قرار دهيم، داده‌هاي موجود در آن را بايد به محيطي منتقل كنيم تا امكان تجزيه و تحليل و ساير اعمال محاسباتي پيچيده بر آن فراهم شود. 

در ابزار جديد Analysis Service مفهومي به نام Unified Dimensional Model) UDM) در نظر گرفته شده كه به معناي ايجاد يك مدل تجاري مجتمع و يكتا با خاصيت چندبُعدي روي يك يا چند منبع اطلا‌عاتي است. 

بر اين اساس، شي يا موجوديتي به نام Data Source View ساخته مي‌شود كه شامل كليه جداول يا ديدهاي يك يا چند بانك اطلا‌عاتي همگون يا ناهمگون است. پس از تعريف اين شي و برقراري روابط ميان فيلدهاي اطلا‌عاتي جداول يا ديدهاي موجود در آن، مي‌توان اقدام به ساخت شِماهاي  چندبُعدي يا همان مكعب كرد.
 
به عنوان مثال، مي‌توان ميزان فروش يك سري اقلا‌م خاص را در طي يك توالي زماني مشخص به صورت يك نمودار سه بعدي نمايش داد. استفاده از اين تكنيك علا‌وه بر رساندن ما به هدف مورد نظر كه همان گردآوري اطلا‌عات گوناگون و تهيه نمودارهاي چند بعدي آماري براساس آنان است، دو مزيت ديگر هم دارد: اول اين‌كه، از انواع منابع اطلا‌عاتي مثل انواع بانك‌هاي اطلا‌عاتي رابطه‌اي، بانك‌هاي ويژه انجام فرايندهاي پردازشي (OLTP)، ‌فايل‌هاي تخت (Flat) يا حتي سرويس‌هاي وب، مي‌تواند استفاده نمايد. 

دوم اين‌كه، به دليل ماهيت فيزيكي cube كه خودش نوعي فضاي ذخيره‌سازي موقت براي داده‌ها است، تداخل خاصي با پردازش‌ها و فرايندهاي در حال اجرا روي اطلا‌عات اصلي موجود در منابع اطلا‌عاتي  نداشته و روي كارايي و سرعت آن‌ها اثر منفي محسوسي ندارد. 

‌●يكي از روش‌هاي مرسوم ذخيره‌سازي اطلا‌عات در سيستم‌هاي بزرگ، تقسيم‌بندي انباره اطلا‌عات (Data Warehouse) به واحدهاي كوچك‌تر با كاربردهاي مختلف مي‌باشد كه به آن Data Mart گفته مي‌شود. بر اين ‌اساس، مثلا‌ً محل ذخيره‌سازي داده‌هاي مربوط به اسناد مالي از محل ذخيره داده‌هاي مربوط به وضعيت عرضه و تقاضاي بازار مصرف جدا شده و هر كدام در محل خاصي قرار مي‌گيرند. در اين حالت دو مشكل مي‌تواند به وجود آيد: اول اين‌كه تعدد Data martها در سازمان به دليل مشكل بودن ايجاد رابطه ميان اطلا‌عات آن‌ها، به كُندشدن هر نوع تجزيه و تحليل آماري مي‌انجامد. دوم اين‌كه، حتي براي گزارش‌هاي ساده‌تر كه فقط روي يك Data Mart بايد انجام شود، به دليل احتمال هم‌سنخ‌نبودن مخازن اطلا‌عاتي با يكديگر، بايد برنامه‌هاي مختلفي را براي گزارش‌گيري يا تجزيه و تحليل اطلا‌عات، مورد استفاده قرار داد. 

با اين حال به لطف وجود Analysis Service، هر دو مشكل مذكور به نحو مطلوبي رفع شده‌اند: اول اين‌كه، ساختار مدل‌سازي واحد (UDM) محيطي متمركز براي نگهداري يك كپي كامل از تمام Data Martها است. ضمن اين‌كه قادر است به هر كاربر و هر دپارتماني از آن سازمان صرفاً اطلا‌عات و تجزيه و تحليل‌هاي مورد نياز خودش را نشان دهد. به اين دسته‌بندي منطقي داده‌ها بر اساس كاربرد، اصطلا‌حا ًPresPective گفته مي‌شود. 

با وجود پرسپكتيوهاي مختلف از يك UDM، هم مسئله تقسيم‌بندي داده‌هاي مورد نياز دپارتمان‌ها حل مي‌شود و هم مشكل لينك شدن اطلا‌عات موجود در Data Martهاي مختلف با يكديگر، برطرف مي‌گردد. اما اين مسئله از نقطه نظر ديگري نيز قابل بررسي است. در گذشته، جدايي و تفاوت بين سيستم‌هاي فرايندي (OLTP) و سيستم‌هاي تحليلي (OLAP) بسيار آشكار بود.
 
سازمان‌ها داده‌هاي خود را در OLTP ذخيره و پردازش مي‌كردند. سپس داده‌هاي پردازش‌شده را به OLAP منتقل مي‌نمودند تا بتوانند بدون تأثير منفي در كارايي و سرعت پردازش‌داده‌ها درOLTP، آناليز اطلا‌عات را به راحتي انجام دهند. اما اكنون و به لطف وجود UDM داده‌هايي كه توسط OLTP پردازش مي‌شوند، بي‌درنگ به OLAP منتقل مي‌گردند. در اين روش محل ذخيره اطلا‌عات مورد نياز OLTP و OLAP واحد است و داده‌ها بر اساس يك مكانيسم بي‌درنگ (Real Time) در هنگام هر نوع انتقال يا پردازش به فضاي مورد نياز گزارش‌هاي تحليلي OLAP آورده شده وcubeهاي آناليزي موجود در آن را بروز (update) مي‌كند.
 
در اين صورت به دليل يكتا بودن محل ذخيره‌سازي اطلا‌عات نيز،‌نيازي به استفاده از برنامه‌هاي مختلف براي دسترسي به مخازن اطلا‌عاتي مختلف نمي‌باشد. بنابراين مسئله گفته شده در اين بند نيز با اين ويژگي جديد حل مي‌شود. 

●يكي از ويژگي‌هاي هميشگي برنامه‌ها و ابزارهاي گزارش‌گيري، امكان كنكاش و تحليل اطلا‌عات در لا‌يه‌هاي مختلف است. به عنوان مثال، يك برنامه گزارش‌گيري مي‌تواند در يك لا‌يه، رابطه ميان فروش محصولا‌ت خود و مشتريان خريدار آن محصولا‌ت را به صورت يك جدول دو بعدي نشان دهد. در لا‌يه ديگري، همين برنامه مي‌تواند رابطه ميان فروش محصولا‌ت و كارخانه‌هاي سازنده آن‌ها را بيان نمايد و بالا‌خره در لا‌يه سوم و در صورت لزوم مي‌تواند بين سه فاكتور مذكور يك نمودار سه‌بعدي ايجاد كند كه اين حالت از پيشرفته‌ترين ويژگي‌هاي يك ابزار گزارش‌گيري محسوب مي‌شود. 

با اين همه، نيازهاي كارشناسان تجاري يك شركت محدود به اين نوع گزارش‌ها نمي‌باشد. در برخي موارد يك تحليلگر نياز به در كنار هم قراردادن و مقايسه چندين فاكتور مختلف از چند موجوديت مجزا را دارد. به عنوان نمونه، در همان مثال قبل فرض كنيد مي‌خواهيم روابطي را براساس فاكتورهاي تاريخي قابل محاسبه مثل تاريخ سفارش، تاريخ تحويل، تاريخ ساخت كالا‌ و تاريخ فروش به مشتري را براي چند نوع كالا‌ي مختلف به دست آوريم. 

بنابراين اينگونه گزارش‌هاي چندبعدي با مدل گزارش‌گيري سنتي (سلسله مراتبي) يا نمودارهاي ساده موجود در آن‌ها قابل ايجاد نمي‌باشد. اما Analysis Service راه‌حلي را براي نيل به اين هدف در نظر گرفته كه جزء ويژگي‌هاي مدل چند بُعدي (UDM) آن است و به نام ابعاد مبتني بر خصوصيت (Attribute Based Dimension) شناخته مي‌شود. 
براساس اين ويژگي، تحليلگران قادر خواهند بود تجزيه و تحليل اطلا‌عات خود را نه به شكل سلسله مراتبي (كه در روش سنتي ميسر بود)، بلكه به صورت همزمان و چندبعدي انجام دهند. مثلا‌ً مي‌توان با اين روش آمار هر نوع خصوصيت كالا‌ي فروخته شده مثل رنگ، اندازه، وزن، واحد و... را به صورت يكجا و در قالب ابعاد مختلف ويژگي‌هاي كالا‌ها، به دست آورد. 

همچنين با استفاده از قابليت ديگري كه به آن <ايفاي نقش> يا Role Playing مي‌گويند، مي‌توان يك ويژگي را به عنوان مبناي يك تجزيه و تحليل قرار داد و آن‌گاه ويژگي‌هاي ديگر هم سنخ آن را به عنوان ابعاد ديگر آن تحليل بررسي نمود. مثلا‌ً مي‌توان فاكتور زمان (روز، ماه، سال و ...) را به عنوان يك ويژگي عام در نظر گرفت و آنگاه تعداد كالا‌ي خريداري،  فروخته شده و تحويل شده را براساس آن فاكتور زمان به عنوان ابعاد ديگر اين تحليل معرفي نمود و با يكديگر مقايسه كرد. 

● يكي از روش‌هايي كه OLAPهاي سنتي براي جلوگيري از كاهش راندمان سرور اصلي بانك‌اطلا‌عاتي به كار مي‌بردند اين بود كه از سرور ديگري براي گرفتن گزارش‌هاي تحليلي استفاده مي‌نمودند. سرور دوم شامل همان ساختار بانك اطلا‌عاتي سرور اول بود و داده‌ها نيز در يك تناوب زماني مثلا‌ً در نيمه‌هاي شب و هنگام كاهش ترافيك شبكه، به سرور دوم كپي مي‌شد. اين شيوه براي كاربردهايي چون تحليل درآمدهاي ساليانه يا ساير تحليل‌هاي درازمدت با كاربرد مشابه، كار معقولي به نظر مي‌رسيد.
 
اما براي كاربردهايي كه نياز به بررسي آني آخرين وضعيت براي برنامه‌ريزي كوتاه‌مدت داشت، روش مناسبي نبود؛ چرا كه امكان داشت هنوز آخرين اطلا‌عات به سرور OLAP (سرور دوم) كپي نشده باشد. سيستم‌هاي برنامه‌ريزي توليد از جمله سيستم‌هايي بود كه نياز به داشتن چنين گزارش‌هاي كوتاه مدتي داشت. در Analysis Service اين مسئله با كپي‌شدن آني و بي‌درنگ داده‌ها به سرور OLAP در حين انتقال به سرور اصلي حل شده است. با اين كار داده‌ها بلا‌فاصله در سرور دوم و در محل cubeهاي ساخته‌شده قرار مي‌گيرند و حتي تجزيه و تحليل‌هاي موجود نيز به صورت بي‌درنگ بروز مي‌شوند. اين خاصيت، مهم‌ترين ويژگي يك سيستم BI پيشرفته امروزي به شمار مي‌رود.